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Designer's Workbench, an interactive approach to integrating de- 
sign aids, overcomes most impediments that normally restrict the use 
of these aids. Written under the pwb/unix* operating system, these 
programs smooth the flow of data between the application programs 
that reside on various computer systems and are used to aid in the 
design of transmission equipment. This paper describes the user 
environment. It includes a description of the design technologies, 
processes, and aids and presents the Designer's Workbench approach 
to improving the acceptance and efficiency of those aids. 

I. INTRODUCTION 

Designer's Workbench (dwb) integrates the design aids used at two 
transmission area locations of Bell Laboratories into a uniform sys- 
tem. 1 The set of design aids at the Holmdel, New Jersey location is 
primarily used for computer architecture and printed circuit board 
design. The set of aids at the North Andover, Massachusetts location 
is used to design custom electronics from the silicon chip through the 
printed circuit board interconnection. Before Designer's Workbench, 
these aids consisted of more than 40 programs running on 12 different 
computer configurations at 9 physically separate locations. 

A major reason for the lack of acceptance of many design-aids 
systems is that little attention has been given to the needs and limited 
level of computer expertise of the user community. The users' require- 
ments have been the controlling force in the implementation of De- 
signer's Workbench. The capabilities and functions they require are 
extensive. Foremost, they need a fully integrated set of application 
programs for electrical design, test development, and physical design. 

* UNIX is a trademark of Bell Laboratories. 
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Besides the necessary application programs, they require: 
(i) Ease of data entry. 
(ii) Ease of data modification. 

(Hi) Automatic naming and maintenance of internal files. 
(iv) The ability to move data from one computer to another. 
( v) The ability to have data translated from one application pro- 
gram to another. 

(vi) Information about missing and inconsistent data before an 
application program is initiated. 

( vii) Automatic formating of the job control language (jcl) for the 
various application programs and machines. 

(viii) Interpretation and cross-referencing of their output data. 
(ix) Interactive dialogue at multiple skill levels. 
(x) A self-learning environment with on-line manuals. 
The needs of the departments that support design-aids systems also 
affect the user environment. One goal is to reduce the dependence on 
consultants, or "gurus," for each application program that is supported. 
Other goals include the support of users who possess a wide diversity 
of skill levels, speeding the access by users to new applications pro- 
grams that were not developed at the local site, and introducing bug- 
free enhancements to existing software. 

This paper first explores the state of the design-aids used before this 
project was undertaken. The viewpoint is the users, that is, the 
electrical designers, physical designers, and test developers. Then the 
present user environment under dwb is discussed, including the dwb 
tutorials, data entry and modification, job preparation, job submission, 
and postprocessing of output data. The paper concludes with user 
feedback, user statistics, and future directions. 

II. TECHNOLOGY FOR TRANSMISSION EQUIPMENT 

Telecommunications equipment for digital transmission contains a 
wide range of both electrical and interconnection technology. 

2. 1 High volume custom electronics 

Equipment that interfaces voice frequency lines contains hybrid 
transformers, relays, plugs, jacks, analog filters and amplifiers, signal- 
ing control circuitry, encoders, decoders, multiplexers, demultiplexers, 
compressors, expanders, etc. Although most of these functions are 
implemented with analog circuitry, significant portions are realized 
with digital circuitry. The logic structure of this circuitry is generally 
random, asynchronous, and sequential. Because of the large manufac- 
turing volumes, custom, rather than off-the-shelf, electronics is used. 
The custom digital technology includes ttl, iil, ecl, and mos. 

Because of the few codes and large manufacturing volumes involved, 
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the line interface product includes a level of interconnection of elec- 
tronics not generally found in other types of equipment. Most other 
equipment interconnects the electronics at the silicon level and the 
printed circuit board level. However, there is an intermediate level of 
interconnection in this product. This intermediate level of intercon- 
nection is the interconnection of digital devices, linear devices, thin- 
film resistors, and/or thin film capacitors on ceramic modules. These 
modules are called hybrid integrated circuits (hics). Thus the design 
process to realize a circuit pack involves three levels of electrical and 
physical design: the silicon integrated circuit (sic) level, the hybrid 
integrated circuit (hic) level, and the circuit pack level. 

The advantages in choosing a customized electrical and intercon- 
nection approach include: 

(i) Lower interconnection cost. 

( ii ) Lower power consumption. 

(Hi) Higher speed electronics. 

(iv) Higher packing density. 
(v) Higher reliability. 

( vi ) Lower manufacturing cost because of automation of processes. 

On the negative side, development times are generally longer and 
capital investment is generally higher. 

2.2 Electronics for low volume control functions 

Transmission equipment that interfaces digital lines or switching 
equipment is generally realized in a much more structured form than 
the voice frequency interfaces. The circuit packs contain dips, micro- 
computers, and memories, and are characterized by common hardware, 
custom firmware, and many different codes. At times, custom msi and 
LSI will appear on the packs. The advantages of this approach include: 
(i) Fast turnaround of designs. 
(ii) Quick response to engineering changes. 

(Hi) Manufacturing economies by use of high volume components. 
(iv) Greater commonality of design aids. 

III. DESIGN PROCESS 

Although the design processes for the above two equipment archi- 
tectures and interconnection technologies are similar, there are basic 
differences in the sequence and way these steps are carried out. These 
differences are mainly due to technological constraints and the avail- 
ability of design tools (with their consultants). The major steps in the 
design process are: 
(i) Design 

(a) Architectural level 

(b) Functional level 
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(c) Algorithmic level 

(d) Logic level 

(ii) Testability analysis and incorporation 
( Hi) Design verification 

(a) Hardware simulation (breadboard) 

(b) Software simulation 
(iv) Timing analysis 

(v) Test development 
(vi) Partitioning, placement, and layout 
(vii) Processing and assembly 
(viii) Prove-in testing on test machine 
(ix) System test, evaluation, and modification 
(x) Documentation for manufacture 

(a) Schematic diagram 

(b) Physical design information 

(c) Test information 

(d) Consistency checking. 

The design process can be split into three major phases, the simu- 
lation and breadboard phase, the test development for manufacturing 
phase, and the physical design and documentation phase. Engineers 
who take the full custom route must repeat each phase in the process 
for each level in the hierarchy (sic, hic, circuit pack). 

IV. DESIGN AIDS 

The design aids for digital electronics have been developed by many 
different computer-aided design groups over the past decade. Some of 
these groups are internal to Bell Laboratories, others are outside 
suppliers. This section describes the state of design aids in the trans- 
mission area of Bell Laboratories in early 1978. 

4. 1 Circuit pack design aids 

The circuit pack design process is illustrated in Fig. 1. Coding of the 
engineer's circuit sketch in the lsl circuit description language 2,3 is 
the entry point for the design aids system. The inclusion of physical 
design information along with the interconnectivity information en- 
ables the creation of the hiwire 4 data base for that board. This data 
base is used as input to the programs that create information to drive 
either an automatic wirewrap machine or a semi-automatic quick 
connect machine for quick turnaround breadboard models. The hi- 
wire coding can be used as input to the lamp 2, 3 logic simulator for 
design verification and test development. When the test data are 
combined with the physical design information provided in the hiwire 
description, diagnostics can be created for guided fault isolation. 

When the electrical designer is reasonably confident that his bread- 
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board meets the design intent, layout for manufacture begins on a 
computer-aided layout and documentation system. To ensure that the 
layout agrees with the schematic, a connectivity comparison is per- 
formed between the initial lsl coding and the metal-to-metal inter- 
connectivity derived from the layout data base. 5 Only when the two 
are in agreement are assembly and art master drawings created. 

The file structure, libraries, and flow of information between major 
programs for the electrical portion of this design process is shown in 
Fig. 2. Note that there are five libraries (package, component, I/O 
pins, simulation, and test) that must be created and maintained, and 
numerous internal files whose data must be compatible with more 
than one program. A list of the functions performed in this process, 
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Fig. 2 — Circuit pack design aids. 
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along with the number of programs and computers used is given in 
Table I. This process required 17 programs, which ran on seven 
different machines. 

4.2 Custom electronics design aids 

As another example of the complexity of the use of design aids, 
consider the test development process for the hierarchy of custom 
electronics (Fig. 3). Test development for custom silicon and hybrid 
integrated circuits is generally done using the lamp simulator. The 
test sequences first exercise the chip's functions and then structurally 
exercise nonactivated gates. They are used to verify the performance 
of the silicon. Loading the device tester at our Allentown, Pennsylvania 
location first required transmission from lamp (run under IBM tss at 
Naperville, Illinois) to our CDC cyber machine at North Andover, 
Massachusetts, then to the computer-aided silicon design system at 
Allentown, which generated a test tape for the device tester. These 
data transmissions were accomplished using a multipurpose batch 
station (mbs) over the interlocation computing network or over dial- 
up lines. 

For circuit pack test development, one available tool is an outside 
supplier's automatic test generator. Translating the circuit description 
from lamp to that test generator required the use of programs on both 
the cyber and a HP 2100 computer. As a check for consistency, the 
vectors generated by the test generator were run against the initial 
coding of the circuit description on the lamp simulator. The test 
development process required interaction with 13 different programs, 
residing on 11 computers, from 9 manufacturers, at 5 geographic 
locations. The process involved 11 hand carry links and 8 data trans- 
missions. 



Table I — Circuit pack design aids 





Number 






of 




Function 


Programs 


Computers 


Breadboard 


5 


IBM OS/370 


Testability analysis 


1 


IBM TSS/370 


Design verification, test 


3 


IBM TSS/370 


generation, and diag- 




IBM OS/370 


nostics 






Schematic capture 


3 


DEC PDP-15 
DEC PDP-11 
IBM OS/370 


Layout 


1 


DEC PDP-11 


Metal extraction 


1 


DEC PDP-11 


Connectivity audit 


1 


CDC CYBER 72 
IBM OS/370 


Test set 


2 


Data General Nova 
Computer Automation 
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Table II — Custom electronics design aids 





Number 






of 




Function 


Programs 


Computers 


Design 


4 


CDC CYBER 72 


Design verification, test 


7 


IBM TSS/370 


generation, and 




HP 2100 


diagnostics 




CDC CYBER 72 
Univac 1108 
IBM OS/370 


Timing analysis 


1 


HP 2100 
Harris 


Layout 






Silicon 


2 


HP 21MX 


HICs & PCBs 


1 


DEC PDP-11 


Prove-in testing 






Column editor 


1 


CDC CYBER 72 


Derace vectors 


1 


CDC CYBER 72 


Test sets 


3 


Fan-child FST2 
Data General Nova 
Teradyne M365 


Translation 






Simulator to simulator 


2 


CDC CYBER 72 


Simulator to test set 


2 


CDC CYBER 72 



A list of the functions performed in the custom electronics design 
process is given in Table II. It includes the number of programs used 
and the host machines. For the entire process, 24 different programs 
are used. 

V. DWB INTERACTIVE APPROACH 

Like many design aids systems, the above systems did not gain ready 
acceptance by new or inexperienced computer users. A major reason 
is that the users generally faced a significant learning curve while 
trying to meet tight design schedules. Because of this learning curve, 
they relied on tried and true procedures rather than contending with 
numerous languages, passwords, phone numbers, file systems, libraries, 
cryptic unintelligible instructions, and error messages. These obstacles 
have been overcome in dwb by creating a "friendly," circuit-designer- 
oriented environment. This environment uses a minicomputer with 
the pwb/unix operating system 6,7 and provides the communications 
between the user and the application programs, which reside on many 
different main frame computers. This system effectively acts as a 
highly intelligent terminal to buffer the user from the intricacies and 
inconsistencies of the various main frame computers and application 
programs. 

5. 1 The environment 

To control Designer's Workbench, a user must have access to a 
computer with the pwb/unix operating system that offers the package 
of dwb programs. 
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A new user must first have the staff of the computer department set 
up a valid user identification for the computer on which Designer's 
Workbench resides. To provide control and security, the dwb librarian 
must then add a user's name to the valid user file and appropriate 
project file. The user is now ready to start an interactive session on 

DWB. 

When the user logs into the computer, he or she will see the pwb/ 
unix operating system. The user next executes the Designer's Work- 
bench program from pwb/unix and is prompted for his or her last 
name. If the user is new to Designer's Workbench, a user profile is set 
up by interactively prompting for required information. This profile is 
saved to be used in later sessions. The profile is built efficiently by 
requiring only the necessary information to do the task at hand (see 
Fig. 4). If additional information is needed for a specific application 
program, it will be prompted for at the time that program is accessed 
and added to the profile. Parameters that have logical and commonly 



login: bin23 
password : 



Dec 20 U.29.S2 EST 19^9 
S dwb 

Ace you a new user ly 
Please enter: 

3 password - > ating password 

please verity oy t- 

vour first name is > 

vour initials are --> g» 4821 

your department number^ ^ 

your phone *■*•*,"> lg56 

JS SSSfSJT- -> - 

Y OU c Eitst name is c"" 

£", initio; «; ■* t , „j, 

S5 &&&?•?- 



_> i logout 

D „B: please type command 



Fig. 4— Initial session of new user. 
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login: bin23 
Thu Dec ZB 



on this LB DWB-V.«ion 1.2 ft 
Please enter yo pa sswotd 

P1" B ' e aee r you again chet. queS tion. 

Gl v. ,o type h elP l» response 

l£ y ou need help. tYP fco k _ n ^^ 

0K chet, Y° u logout 

. tvD e command 
DWB: please type 



Fig. 5 — Session of user known to dwb. 

accepted default values are automatically set. However, the user may 
reset these or any other parameters at any time. 

If, however, the user is recognized as one who has previously used 
dwb, the logon procedure continues with a friendly greeting and 
prompts for a password (if needed for security), project name, and 
finally circuit name (see Fig. 5). 

From then on, all commands, edits, and operations will be automat- 
ically performed on files associated with this particular circuit. Each 
circuit has a profile that grows and changes according to the actions 
taken by the user and is used to store items such as library names, 
data types, and process keywords. 9 

The user has no knowledge of actual file names, file types, or naming 
conventions that other computer-aided design systems require. File 
maintenance is greatly simplified by using generic file names. For 
example, the file containing the electrical and physical circuit descrip- 
tion is accessed by typing "lsl", since it is a variation of the lsl-local 
language. The file of input stimuli for logic simulation is accessed by 
typing "vectors." These and other keywords are used to describe the 
files that the system maintains for a particular circuit. 

The interactive session focuses on one project and circuit. However, 
to change from one circuit to another, the "circuit" command is issued. 
Projects can be changed in a similar manner, but only if the user has 
authorization to access that project. 

5.2 Tutorials 

Users cannot be expected to operate a multioptioned software pro- 
gram without guidance and sources of reference. Printed manuals and 
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user guides are available to study when there is time, but typically an 
unfamiliar technique is needed or a question arises while the user is 
on-line and in the middle of the job. The quick and easy-to-use series 
of on-line tutorials in Designer's Workbench eliminates the problem of 
hunting through manuals or, worse yet, stopping the session to go look 
for the answer somewhere else. 

dwb is designed to let the user enter the tutorials at any time by 
typing the keyword help. A new user who enters the tutorials from the 
dwb command level has a menu of topics that explains the commands 
of interest. More details on special commands, utilities, application 
programs, or options are available if the user asks for information by 
entering the keywords that are provided. The tutorials are organized 
in a hierarchical manner, allowing the user to pursue as much or as 
little of a topic as needed. In addition to the hierarchical approach 
implemented to learn a topic for the first time, dwb has the feature 
that, if the user asks for help in the middle of a task, the section of the 
tutorial that pertains to the work at hand is immediately available. 
This saves the knowledgeable user from having to search for the 
information in an index mode. The user can end the tutorial session at 
any time and is ready to resume the job at hand, from the exact place 
in the program before the "help" command was requested (see Appen- 
dix A). 

5.3 Data entry and modification 

Data entry is always required to use computer-aided design pro- 
grams. It is time-consuming and prone to human errors and misunder- 
standings. A goal of dwb is to make this step as easy as possible, yet 
flexible enough to serve the needs of the user community. Data entry 
takes two forms, directly appending information from a terminal or 
transferring data prepared somewhere else. Details on the transferring 
of files is discussed in its own section and is not discussed here. 

Direct data entry through a terminal is provided using either the 
standard pwb/unix editor or the dwb "easy" editor. The "easy" editor 
has been designed to meet the needs of users who do not have 
computer editing experience. The pwb/unix editor is available to 
users who are experienced with computer systems and may profitably 
use the powerful and flexible features of the current generation of 
context editors. 

For data entry and modification of test data, two additional features 
are available. One is a vector input language that allows a shorthand 
method of entering "one, zero" information, and the other is a colum- 
nar editor. These programs are used to build up the data files quickly 
and with a minimum of errors. The output files of these programs can 
be edited using the text editors. 
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Either editor can be used by the user to enter or modify any or all 
the user files. These files are accessed using the easy-to-remember 
generic names instead of actual file names, dwb again maintains the 
files and keeps track of names, types of data, and access dates for 
consistency checking. 

Another form of data modification that does not use the editors 
should be mentioned, dwb provides default parameters at the circuit, 
project, or global levels. To modify parameters of the user's profile or 
of the circuit or project profile, a special "change" routine is provided. 
The user can at any time change the default conditions and the other 
parameters of the profiles. 

5.3. 1 Easy editor 

The "easy" editor is designed to be used with the minimum amount 
of learning. It is similar to creating a punched card deck using a 
keypunch machine. The commands are immediately recognizable and 
the functions are basic. The user can append, change, delete, find, 
and list lines of the file to be edited. Alternatively, a, c, d, f, and I 
could be used. Operations are on a line-by-line basis, and the new file 
is saved only if the user says "yes" to the question concerning saving 
the new file. This "easy" editor is used to introduce dwb to new users 
who do not have a background in text editing. 

5.3.2 Standard editor 

The second editor is the standard pwb/unix editor, but it is accessed 
through the dwb program. This editor is extremely powerful, with 
string location, string modification, metacharacters, and global com- 
mands that can process complete files using a single complex state- 
ment. This power comes with a price, however, and that price is a 
longer learning period and less-than-clear command constructions. 
This editor is included in dwb to meet the needs of the growing user 
population who have learned this editor and feel at home using it. 

5.3.3 Vector input language 

The vector input language is not an editor but a powerful program 
to generate the stimuli for logic simulation or test set programs. It is 
described here since it is an important feature of the dwb interactive 
environment and does not exist in other computer-aided design sys- 
tems. 

The vector input language has features to allow the "one, zero" 
information used by logic simulators or test sets to be entered either 
in a timing relationship (functional form) or in a spatial relationship 
(test generation form). Control statements and macros allow the data 
set to be built quickly, understandably, and almost error-free. 
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5.3.4 Column editor 

The column editor is another feature of dwb not found in many 
design-aids systems. Stimuli data for simulation programs and test 
sets have the characteristic that information for a test lead is stored in 
a column form rather than in a row form. While context editors easily 
handle lines or rows, most are clumsy if column manipulations are 
needed. 

The column editor can add, change, and delete columns as easily as 
context editors edit lines. Moving columns and complimenting data in 
columns are commonly needed actions, but would be difficult to do 
without the column editor. 

5.4 Job preparation 

The environment that the user sees is friendly and easy to use when 
application programs are run. Although the application programs are 
run on computers located remotely from the user, the job is initiated, 
monitored, and retrieved under the control of dwb. For the application 
program selected to be run by the user, dwb provides the following 
preparation services: 

(i) The circuit files are checked to see if they have been modified, 
thus invalidating output results that may have been obtained previ- 
ously. 

(ii) Missing data to run this option of this program are requested 
and added to the circuit profile. 

(Hi) The proper translators are invoked to build data files in the 
proper languages of the application program selected. 
The following sections expand on these features. 

5.5 File and job checking 

Many user problems are caused by omitted information unknown to 
the user or by misunderstandings about the operations to be per- 
formed. Designer's Workbench has many checks and audits incorpo- 
rated to protect the user from wasting time and resources running 
application programs with wrong data. 

5.5. 1 Syntax checking 

Checking starts with a syntax check and verification of the input 
data supplied by the user. If information is missing, it is interactively 
requested and can be added by the user just before the application job 
is run. Note that only information needed to run the application of 
interest is required. Once this information is known, it is added to the 
profile of the circuit and used automatically in future runs. 
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5.5.2 Library checking 

To insure that library elements referenced in a circuit description 
are available on a remote machine, a directory listing of remote 
libraries is kept on dwb. This listing is updated periodically. If dwb 
has the library element in its data base, this element is added to the 
job deck before submission to the remote machine. 

5.5.3 Consistency checking 

Checking is also done to inform the user about the proper order of 
doing things, dwb checks to be sure that the user runs application 
program A before application program B if it is required. Audits are 
made of the times files were last changed and application programs 
last run to detect any inconsistent conditions. If the user modifies the 
circuit description after an application run has been made, the output 
files will not agree with the current input files. The user is informed 
that the input and output are now out of phase with one another. This 
feature is particularly helpful to users who develop new circuit designs 
that change during the design cycle. Physical design, logic simulation, 
and test generation are kept in step with the "current" circuit descrip- 
tion. 

For example, to run the flint application program, 4 an automatic 
test set program generator that includes guided probe diagnostics, first 
the lamp logic simulation program and then the hiwire physical 
connection program must be run (see Fig. 6). dwb keeps track of the 
steps executed, the order and if changes were made after some steps 
were completed. The checks to properly run flint are listed below: 
(i) Check syntax of lsl input. 
(ii) Run lamp compile before lamp run is allowed. 

(Hi) Check syntax of vectors before lamp run is made. 
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Fig. 6 — Running flint application program. 
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(iv) Run hiwire before flint. 
(v) Run lamp before flint. 
(vi) Run flint only if hiwire and lamp use same lsl input. 

5.5.4 Test vector checking 

Before a job is submitted to a remote computer, the test vectors are 
checked for consistency with the circuit description and for legal vector 
values. 

5.6 Data translation 

An important ability of Designer's Workbench is to translate data 
files from one form into another. The input language used in dwb to 
describe the physical and logical interconnections of a digital circuit is 
based on lsl-local. The lamp logic simulation program uses one 
dialect of lsl-local, while the hiwire model building program uses 
a different dialect of lsl-local. Designer's Workbench provides the 
user with an automatic method to translate from one dialect to another 
and even to completely different languages. For example, dwb can 
translate into the logic description language for lasar 8 and for the 
Computer Automation (cai) simulator. 10 Appendix B illustrates the 
conversion from the lsi-local language to the lasar language. Other 
user files such as input vectors are also translated from one form into 
another. The "one, zero" form for lamp becomes the "hi, low" for 
lasar or a different "hi, low" for cai. 

Using the single master description stored on dwb, the user is able 
to translate into logic simulation languages, test generation languages, 
and physical model building languages, and into test program lan- 
guages for automatic test equipment. The translators of dwb can easily 
interface to new applications as needed, yet provide the user with a 
single circuit description and test vector set to update and maintain. 

To accomplish this, both the circuit description and test vectors are 
first translated into a neutral form. For the circuit description, this is 
a set of tables that contains component and connectivity information. 
Then the information is translated from the neutral tables into the 
target language. 

VI. JOB SUBMISSION 

A major feature of dwb is the semiautomatic or automatic submis- 
sion of runs to remote computers and obtaining results from those 
computers. This section describes the elements of that process. 

6. 1 Communications network 

Designer's Workbench uses the extensive communication capabili- 
ties of the pwb/unix operating system for this function, pwb/unix 
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has a high-speed synchronous data link into the Bell Laboratories 
Interlocation Computing Network. These links operate at 4800, 9600, 
or 56000 baud, depending on the computers involved. Each computer 
system is assigned a unique identification and is a node on the network. 
The job control language directs the flow of information allowing a job 
to be sent to a remote site to be processed and have the results sent to 
a different location. The interlocation computing network provides the 
path to most application programs used by Designer's Workbench. 

For those application programs that cannot be accessed through the 
Bell Laboratories Interlocation Computing Network, pwb/unix has 
alternate means used by dwb. pwb/unix has a call-originating feature 
that allows users to connect to the asynchronous time-share ports of 
remote computer systems. The dialing of the telephone number and 
the setup of the data lines is automatically provided as a pwb/unix 
feature, dwb uses this feature to communicate with systems not on 
the network. 

6.2 Distributed database and libraries 

The creation and maintenance of large data bases has always been 
a significant technological challenge. This, combined with the desire 
to minimize the amount of data transferred between the host computer 
on which dwb resides and the remote computer on which the appli- 
cation program resides, lead to the implementation of a distributed 
data base. Only enough data are transmitted to insure that all the 
required information can be reconstructed on the remote computer. 
The existence of separate data bases requires that dwb provide the 
consistency checking described above to insure that only consistent 
information is retained. 

For example, instead of maintaining a complete library for all 
application programs on dwb, only cross-reference listings of libraries 
that exist remotely are maintained. If a user uses a subnetwork 
description of a function or part that exists on a library, this is quickly 
checked to see if it is in the current cross-reference library. Warnings 
are given to the user if dwb is not aware of the existence of the 
subnetwork. 

6.3 Transferring files 

The transfer of information from one person to another or from one 
physical location to another is often required, especially if the system 
and logic design is done at a different location from the fabrication or 
from the location of the computer-aided design programs that are 
used. The transfer process has been a major problem to users. Each 
location has different equipment, techniques, and formats that are 
unfamiliar to all but a few experts. Designer's Workbench can com- 
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municate with many different programs and different computers at 
locations remote to the user. 

Most transfers are done automatically by dwb without the direct 
involvement of the user. For example, the running of application 
programs generates a data file transfer from the local system to the 
remote main frame computer. Completion of the job generates a data 
file transfer from the remote site back to dwb. This transfer is also 
done automatically. 

A request for a file transfer from a remote computer to dwb can be 
done under user control and is often used to create the user files for a 
new circuit or to return results from application programs that have 
been run. The method of transfer will either be to submit a copy 
request using the proper job control language of the remote computer 
or to have dwb simulate an interactive time-share session. The user in 
either case must only supply the file name, location, and security 
requirements. Designer's Workbench will generate the proper job or 
protocol to successfully acquire the data. Transfer of a dwb file to a 
remote location is handled in a similar manner. 

6.4 Submission options 

Currently, applications programs can be run on remote systems in 
three ways. They are remote batch mode, interactive mode, and 
remote auditing mode. This section describes the implementation of 
those modes. 

6.4. 1 Remote batch 

This mode involves combining the constituents necessary to run a 
batch run on a remote computer, submitting the card images over the 
computer network, and receiving the results via the computer network. 
Features include: 

(i) A job is created to run on the remote computer inserting the 
customizing information from the user profile, the circuit profile, and 
the global profile. 

(ii) The maze of accounting and job control statements is hidden 
from the user. 

(Hi) The data files are merged with the job control statements and 
program commands at the correct places. 

(iv) The newly created job is automatically sent to the remote main 
frame, and the job is initiated. 

(v) The outputs from the remote application program are sent via 
the network to the home location's computer printer. 

6.4.2 Interactive TSS 

Programs, such as lamp, that run on the Time-Share System (tss) 
can be accessed in two interactive modes. For both modes, dwb dials 
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the remote machine and handles the logon (including encrypted pass- 
words). In the direct mode, the user works on tss as if the connection 
were made without the interjection of dwb, that is, as if the user had 
dialed directly. In the other mode, each command issued by the user 
is translated into the proper tss command, and the responses from tss 
are translated into user-understandable English. An example of this 
later approach is given in Fig. 7, which illustrates the check for the 
existence of a file on the tss machine. 

6.4.3 Remote auditing mode 

lasar is a commercial logic simulation package that runs on a time- 
share system outside Bell Laboratories. Remote batch access is not 
possible from dwb, yet an interactive session is not needed either. The 
remote audit mode of job submission is used to run the lasar simu- 
lation program via dwb. 

The remote audit mode of dwb uses the steps and features of remote 
batch submission except that the data file is sent in real time with the 
user observing the transfer of data and watching for the proper 
completion of the task. If the remote system is down or if transmission 
errors are observed (no error checking on this connection), the process 
can be restarted at a later time. 

6.5 Job and network status 

dwb provides the user with two status functions. The first enables 
the user to determine the status of any jobs that were submitted to 
remote machines by typing status lamp for lamp or status abc for the 
ABC application program. The status of the last job submitted can be 
determined by just typing status. In addition, dwb informs the user of 
expected turnaround times for jobs submitted to remote machines. 



DWB = Please type """^cti" . 
1 am attempting a T ^ 

This may take ,,,. 
Don't go a ^ y -cs'has begun. 
The logon to n ^ "swora... 
•••Processing Security <"£•■• TSS operations. 
■•• P now in the DWB monitor tot dire ct 

you are now in t c0 mmand — > tss 

D CHET**"-D"-BOARDl.LSL 

<TSS> __>dwb command --> bye 

.„„ rvpe command - > 
DWB: please tyv 

Fig. 7 — Interactive check for existence of a file on tss. 
DESIGNER'S WORKBENCH— USER ENVIRONMENT 1785 



This is accomplished by using a pwb/unix utility that periodically 
schedules jobs to be submitted to remote computers and measuring 
their turnaround times. 

6.6 Postprocessing output data 

Output data from application programs are sent to the user as 
printed results or as data sets of cards, magnetic tape, or disk files. All 
printout is automatically directed to the printout bin of the user, but 
data sets are sometimes saved on the remote computer until the user 
is ready to receive the data, dwb's ability to transfer data from one 
computer system to another is used to retrieve data for postprocessing. 
dwb is aware of the actual file names, the date modified, and contents 
of files generated by application programs for each circuit. 

Data files from remotely run application programs often are not in 
the correct format to be used by another application program on a 
different remote computer, dwb postprocesses data from one form 
into an intermediate form that can be translated easily. Then, when 
this information is required, the proper output translator is called. 
Changes in the data structure of one application program can be 
accommodated without affecting the translators to the other applica- 
tions. This translation takes place automatically, and the circuit profile 
is updated to show the status and options available to the user. 

VII. USER FEEDBACK AND STATISTICS 

The user response to the capabilities of dwb has been favorable. 
Inexperienced computer users who formerly would not have used 
design aids because of the significant learning curve have been con- 
verted to dwb. Experienced computer users, who had previously used 
applications programs on remote computers, have used dwb to create, 
check, and transfer files to the remote machine and retrieve output for 
postprocessing and transfer to other applications programs. Programs 
that were only used if there was a local consultant available are now 
seeing heavy use with no consultant available. The amount of time 
spent helping users solve jcl problems and use applications programs 
has been reduced by 80 percent. Significant effort has been required to 
match the tutorials and procedures to the thought processes of the 
user community. Most of the usage of the two design-aids systems that 
were integrated into dwb have shifted to the workbench. 

The most significant requests for new capabilities have been to 
replace the predominantly batch-type operation with a fully interactive 
mode for executing programs on other computers and to provide 
completely automatic data transfer capability between all major com- 
puter systems in Bell Laboratories. The tutorial help has been found 
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so popular that the user community has requested that the same type 
of help and guidance be provided for all interactive programs. 

dwb was introduced to a limited number of "friendly" users in 
September 1978 and, after thorough testing, to the general-user com- 
munity in January 1979. Since the beginning of 1979, we have seen 
steady growth of its use. The greatest portion of the use is in data 
preparation and syntax checking before submission of a job to a remote 
machine. In November 1979, usage totaled 519 logon hours and 111 
application program submissions, with about 65 percent from the New 
Jersey location and 35 percent from the Massachusetts location. As 
more features and applications programs are added, we expect these 
figures to increase significantly. 

VIII. NEW FEATURES 

This section describes features that were not in the original specifi- 
cations of dwb but have been already added or are in the process of 
being added. The modular development of dwb allows the requests of 
the user community to be addressed quickly and implemented without 
much of a change to sections already in use. 

8. 1 Testability analysis 

dwb offers the user two capabilities for evaluating the "testability" 
of a circuit. The first is an interactive question-and-answer session 
between the user and dwb that qualitatively evaluates the testability 
of the circuit. Questions are asked about the design of the circuit to 
ascertain its inherent testability based on the strategy that previously 
had been applied manually by test engineers. Then dwb provides 
suggestions on how to improve the design of the circuit to make it 
easier to test. A report is automatically generated that summarizes the 
results of this testability review. 

The second is the tmeas 11 program that uses the lsl-local input 
circuit description language to evaluate the observability and control- 
lability of the various parts of the circuit. The user is provided with a 
quantitative figure of merit on the testability of the design and a list 
of problem areas, if any exist. The program can be used interactively 
as an aid in resolving testing problems by providing insight into the 
value of additional test access. 

8.2 Analog circuit design aids 

dwb uses the lsl-local language to describe digital components, 
both electrically and physically (hiwire form). Analog components 
have been added by a new analog circuit description language. Tables 
are built for all components, and these tables are available for the 
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various output translators to use. We are planning to establish links to 
both analog circuit analysis tools and physical design systems. 

8.3 Interface to silicon design process 

The silicon design process includes using lamp for logic simulation 
and test generation. This dwb does as a regular feature. The timing 
analysis that is important for mos lsi silicon chip designs uses the 
motis 12 program. Input to the motis simulator is another dialect of 
lsl-local and input stimuli in a native motis form. DWB with its 
ability to transfer data and its translation programs is now integrating 
the motis timing simulator into the remote application program selec- 
tion. Further connections can be made in the future to lay out and test 
generation aids for silicon chips. 

8.4 Downloading physical design process 

The physical design process in the transmission area uses minicom- 
puter based graphical data entry and editing stations from Applicon, 
Inc. Using these tools, the schematic diagram of the digital or analog 
circuit description can be captured and sent to dwb in the lsl-local 
(digital components) and ucl (analog components) circuit description 
languages, dwb will audit and compare the physical schematic capture 
with the data stored on Designer's Workbench, if it exists, or will use 
the data to build the tables used by other programs. 

To help check the physical design process, dwb will initiate on the 
remote computer an audit of the connectivity of the physical printed 
wiring board, hybrid, or chip with the electrical connectivity used for 
model building, simulation, and test generation. 

IX. CONCLUSIONS 

The Designer's Workbench approach has greatly increased the user 
acceptance of design aids programs. Most user complaints about the 
aids have been removed by shielding the user from the idiosyncrasies 
of the computers, both the job control language and the input lan- 
guages of the programs. In addition, most tedious, error-prone steps of 
data encoding, file management, consistency verification, and job 
customization have been removed or greatly simplified for the novice 
user without restricting the flexibility provided for the experienced 
user. Furthermore, it has created an environment in which new appli- 
cations can be readily written and integrated with the existing aids. 

The program modules and utilities that were written as part of dwb 
and the utility programs available from UNIX provide a solid foundation 
on which to build. Finally, Designer's Workbench is inexpensive to 
use. The operational costs are low because a minicomputer is used for 
the interactive operations while the large programs are run on main- 
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frame computers. Thus, the costs are reduced by using each class of 
computer where it is most efficient. 

APPENDIX A 

Example of DWB Tutorial Session 

DWB: please type command — > run lamp 

Which option for "lamp"? — » help 

lamp options are: build compile cval logic race timing 

DWB DOES NOT SUPPORT THE TIMING OPTION AT THIS TIME! 

For additional information type "more" else type the option 

Which option for "lamp"? — » more 

There are four independent simulators available under lamp: 

1 . cval — a true value simulator which simulates circuit behavior 

without faults 

2. logic — the standard logic simulator which drops star faults 

3. race — a race simulator which flags and propagates star faults 

4. timing — a timing simulator which performs detailed timing 

analysis. 

DWB DOES NOT SUPPORT THE TIMING SIMULATOR 
AT THIS TIME! 

The true value (cval), logic, or race simulators may be accessed by 
the options: cval, logic, or race, respectively. 
Other options allowed are: 

1 . compile — for compilation of your Isl local circuit description 

2. build —to build a flint file on the HO IBM 370 for Datatron 

testing 
For more detail type "tutorial" else type the option. 
Which option for "lamp"? — > tutorial 
***DWB TUTORIAL*** 

Lamp is a set of logic simulation programs used to generate and 
evaluate test sequences. It is a Bell Laboratories product that is 
interconnected to other aids systems. Lsl and vector files are required 
as input. Other optional input files include vecord and lamp command 
files. All output listings are returned to your computer bin. 
Lamp simulates your circuit, using the test vectors you supplied DWB 
and produces outputs according to procedures defined by the option 
selected. 

For even more detail consult the manual "LAMP System-TSS Com- 
mand Language (Version 4)" TM-5936-10. If you have a specific 
question on running lamp on DWB contact the DWB librarian at 
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extension 1 537 at HO or 7893 at MV. For assistance in running lamp 
itself on TSS contact Al Gibson on extension 931 2 at IH. 
You can also get help for: 

build compile cval faults logic Isllocal 

race starflt timing vecord vectors 
Type "end" or a keyword — » compile 

A compilation must be your first run. Your Isllocal circuit description 
is sent from DWB to TSS at IH where it is stored under the user login 
id. The Isllocal compiler is run and your circuit is checked for errors. 
A good circuit is compiled into tables for use by the LAMP true value 
and fault simulators (cval, logic, and race). 
See also: cval logic race Isllocal 
Type "end" or a keyword — » end 
* "END DWB TUTORIAL* * * 
Which option for "lamp"? — »• compile 

APPENDIX B 

Example of Translation from Augmented LSL to LASAR 

1. Circuit to be coded: 



NCLK > 



NTSE> 



TEST> 



A03D 

© 



RESET > 



NTIME> 



RAC 
RSC 



A03D 
© 



■RME 
RCC 



I 



Z1 





2. Augmented LSL coding: 

subnetwk: 

cktname: ao3d; 

inputs: a.b.c; 

outputs: z.zl; 

**pin:in=(1,2,3), 
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out=(4,5); 

nodelay: orlnf; 

•unfault: orlnf(0,1); * unicad only; 

nand: zl,(a,c); z,(zl,orlnf); 

or: orlnf, (b,c); 
•control circuit; 

•options: propt = (nolist), cktsize = 8; 
•option: autorout = .2; 
network: 
cktname: cl; 

inputs: nclk, reset, ntse, ntme, test; 
outputs: rsc, rac, rmc, rcc; 
•*pin: in = (1,2,3,4,5), 
out = (6, 7, 8, 9); 
ao3d: 

a1 , (nclk, ntse, test), (rsc, rac); 
a2, (reset, ntme, test), (rcc, rmc); 
••pd: 
ao3d: 

a1„ loc = (a-22), 
a2,, loc = (a-23); 
3. lasar coding: 
c1 CIRCUIT 
INSERT ao3d 
USEo2 
NAME = o2 
ADD ao3d 
NAME = AA 
MODEL/ 

110na/1, 3/5/1 20na/5, 6/4/1 30o2/2, 3/6/ 
INPUT/1, 2, 3/OUTPUT/4, 5/ 
END 
END 
CIRCUIT 
PI nclk, 1P1 
PI reset, 2P1 
PI ntse, 1 P2 
PI ntme, 2P2 
PI test, 1P3, 2P3 
PO rsc, 1 P4 
PO rac, 1 P5 
PO rmc, 2P5 
PO rcc, 2P4 
DEVICE 
1,2 = ao3d 
END 
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